Mission 3/Mission 3.zip/Mission 3.iso/spiele/sgac/manual/chapter3.doc

Text File | 1989-07-28 | 15KB | 367 lines

                         Chapter three

                       (The Editor Program)

 Once our data is tested we can spruce it up a bit by adding extra
 routines, this is where this program comes in. The editor
 Program is a bundle of routines which handles your saved game
 data from the Creator which allows you to take, drop and examine
 objects, read your location descriptions and so on.

 If you have been playing about with the Test.prg program then you
 will see what I mean, but at the moment we can't access any of
 the other zones except for the Connection and Examine zones.

 So what we have to do is use Stos itself to add the extras, so
 load it up, and insert this disk. The file we want is called
 'editor.bas', so load it up by using the file selector (F4) and
 clicking on "editor.bas" or just type..load"editor".

 Type "list" and press Return. The program is as you see a bundle
 of routines to handle your game data, there are also long lists
 of 'REM' statements, the first 'REM' what the following list of
 statements are used for, our routines go in between these lines.

   Lines 160 to 240   (Varibles)

 These lines are used for your own Varibles, these are set to
 indicate the state of something, for example, if we had a dragon
 in our game we could define a varible called 'DRAGON', this could
 be set to either 0 or 1 depending on the state of the dragon.

 DRAGON=0 : (Dragon is dead)
 DRAGON=1 : (Dragon is alive)

 So we could set the varible to one at the start of the game to
 indicate the dragon is alive and set it to nought if killed.

 Varibles don't just have to be used for life and death, there can
 be used to check if a character has been hit, examined or spoken
 to, In Grannies Garden, a varible has been used to check if the
 keeper of the lake has been given the key and if not, he will ask
 for it. Also the elf in the forest will come up to you every time
 you enter that location until you put the fire out.

 ELF=0 : (Fire has been put out and elf gone)
 ELF=1 : (Fire is still going and elf still there)

 Varibles can have as many values as you want. You could set the
 players energy to ten and take one away from the varible until it
 reaches nought. You can create interesting effects with this.

 ENERGY=10 : (Players energy is up to full)
 ENERGY=5 : (Player is feeling weak)
 ENERGY=0 : (Player is dead)

 See if you can think of anymore ways the varibles can be used.
 But remember that there are two used by the editor program that
 could cause programs if used. They are LO and OB and they hold
 the number of locations and objects.

   Lines 260 to 430   (Game intro)

 This lines are used for an intro to your game, this could be just
 a title screen and some music playing. Once the player press a
 key or mouse button the game can start.

 430 if mouse key then goto 500 (start of game)

   Line 500  (Subroutine to line 9000 for extra routines)

 Before the game allows input to the player this line is used to
 check for any routines at the end of the editor. This is mainly
 used to put drawings of characters on the screen like the guard
 in Grannies Garden, the routines are entered from line 9000
 onwards which are checked at the start of every location.

 ie: 500 gosub 9000

 See EXTRA.DOC for more info on this.

 Don'nt forget to put a RETURN command at the end of each line in
 this section. More on this later.

   Lines 750 to 1030   (High Priority Events)

 These events are used to check the location before giving control
 to the player, these are messages that appear just after the
 location description and imform the player that something has
 happened in the room that they were'nt told about in the location
 description, Such an event could be a character appearing on the
 scene or that the state of something is the location has changed.

 These messages are entered, using the creator, in the Game
 Messages menu, so the messages we need are game messages.

 Lets say that we had a troll at location five and we wanted to
 imform the player of his state, we could first define a varible
 called TROLL which would be set to one if he was alive and nought
 if he was dead. We would enter two game messages in the creator.

   Game message 1

 There is a dead troll here.

   Game Message 2

 There is a nasty looking troll here.

 We then use our H_P event.

 750 if LOCATION=5 and TROLL=0 then print MESSAGE$(1)

 The varible 'LOCATION' holds the number of the location that the
 player is in so in this line first checks if he is in location
 number five, if he is'nt then this line is ignored.

 The MESSAGE$(1) is an array created using the DIM command and it
 loads all the game messages that we entered. so if this line is
 used then game message number one is printed which tells us that
 the troll is dead. We now need one to see if he's alive.

 760 if LOCATION=5 and TROLL=1 then print MESSAGE$(2)

 So if the player is in location five and the troll is alive then
 print game message two to imform the player.

 Other example could be if we wanted to check if the player
 entered a dragons cave, if he was carrying a shield then he would
 be safe from the dragon's fire otherwise he would be burnt to a
 frazzle. To do this we would use an H_P to check the state of the
 dragon, if the player is in the same location and if he's
 carrying the shield. Using the Object Menu, we would create a
 shield object and put it in a normal location.

 We could check this with the following H_P event.

 770 if LOCATION=10 and DRAGON=1 and OBLOC(2)=CARRIED then print
     MESSAGE$(3)

 The OBLOC array holds the location of all the objects in the game
 so this line says, if the player is in location ten (the cave)
 and the dragon is alive and the location of object number two
 (the shield) is carried by the player then print game message one
 to tell the player that the dragon's fire has no effect as he has
 the shield. Here are some more examples of OBLOC.

  OBLOC(1)=5 : (Object 1 is in location 5)
  OBLOC(2)=CARRIED : (Object 2 is carried by the player)
  OBLOC(3)=WN : (Object 3 is worn by the player)
  OBLOC(4)=NC : (Object 4 is not created)

 So, as the player has the shield he is safe, but what if he
 does'nt have it, we can check with this line.

 780 if LOCATION=5 and DRAGON=1 and OBLOC(2)<>CARRIED then print
     MESSAGE$(4) : goto DEATH

 So, if the shield's location is in any other place but carried
 then game message 4 is printed so tell the player he has just
 been burned to death by the dragon. As we want the game to end
 because the player has been killed then we add the "goto DEATH"
 statement at the end of the line, the varible DEATH holds the
 line number of the finish game routine.

 Can you think of anymore H_P events you can use?

   Lines 1380 to 1670   (Special Take Events)

 At the moment, the editor program will put any objects the
 player has just taken and put them in the carried postion, but
 sometimes, taking an object could result in something else
 happening like another object being found or getting caught by a
 character who nicks you for stealing the object.

 This line would check that if a vase was taken, a key would fall
 out of it.

 1380 if TAKE$="Vase" and OBLOC(5)=NC then OBLOC(5)=LOCATION :
      print MESSAGE$(5) : SC=SC+20 : DONE=1

 When the player clicks on an object to take it, the objects ID
 word goes into the varible 'TAKE$' so this varible contains the
 word just chosen by the player.

 As we only want the key to be found when the player takes the
 vase for the first time we use the OBLOC(5) statement to check
 that object 5 (the key) is not created so if he drops the vase
 then takes it again, this line won't be used because the key has
 been created and in another location.

 Now we know that the vase object has been taken and the key has
 not been created (ie: not found yet), we can put the key's
 location at the players present location. The SC varible holds
 the players score and this line adds 20 points to it if the key
 is found, finally we add a'DONE=1' at the end because the line
 has been used by the game.

   Lines 1910 to 2200   (Special Drop Events)

 These events are used in the same way as the Take Events only
 that we can cause things to happen like dropping a vase would
 result in it breaking into pieces.

 When the player selects an object to drop, the objects name goes
 into a varible called 'DROP$', this could be used like this.

 1910 if DROP$="Vase" then OBLOC(6)=NC : OBLOC(7)=LOCATION : print
      MESSAGE$(1) : goto 2300

 We don't need to check the location of the vase (object 6)
 because the editor program will only come to this routine if the
 object is carried and the end of this line goes to line 2300
 which is the player input routine, it stops the object goes to
 the players location as normal.

 We have an interesting feature at this line, we kill one object
 and put another there, Object 6 is a vase and object 7 is a
 broken vase, the broken vase is in the not created location.

 So what happens is, because the vase was dropped, we swap it for
 the broken vase, so the vase goes out of the game by being put in
 the not created location (NC) and the broken vase goes to the
 players location. So the game message in the above line tells the
 player that as he drops the vase it breaks and he sees the broken
 vase at his location instead of the un-broken one.

 An important thing to remember is that when using the 'TAKE$' and
 the 'DROP$' varibles is that the object words put be entered into
 these varibles in the same way as there were entered as Object ID
 Words in the Creator, for example, the Object ID Words in
 Grannies Garden were entered like this.

  Object ID Word="Cake", Object ID Word="Key"

 So the TAKE$ and DROP$ varibles must have the same wording.

  TAKE$="Cake", DROP$="Key"

 Otherwise your game would ignore the lines.

   Lines 2420 to 2710  (Special Examine Object Events)

 As with Take and Drop, we can cause something to happen if an
 object is examined by using a varible called EXAMINE$, in the
 TAKE$ example we saw how a key could be found behind a vase, one
 object found in another, so lets use an Examine Object event to
 enable the player to FIND the key inside the vase.

 2420 if EXAMINE$="Vase" and OBLOC(5)=NC then OBLOC(5)=LOCATION :
      print MESSAGE$(8) : SC=SC+30 : DONE=1

 So, if the vase is examined and the key has not yet been created
 then create it and put it at the players location.

   Lines 2870 to 3160  (Special Examine Location Events)

 As you know, we can examine part of our location by clicking on
 it and the right examine message appears, but what if we wanted
 something to happen like examining a table could result in a
 plate being found, or an passage could be found by examining a
 wall. This is where these events come in.

 The Location Message option in the creator sets up these Examine
 Zones and allows you to enter the examine message for the zone,
 and as mentioned in Chapter 2, we can insert a false Examine Zone
 just by pressing 'RETURN' without typing anything in.

 We can take control of these zones in this section by defining
 the examine messages for the false zones as Game Messages, this
 line would create an hidden passage.

  2870 if Z=2 and and MAP(4,2)=0 then MAP(4,2)=5 : print
       MESSAGE$(9) : DONE=1

 As you know, each picture can have up to five zones for each Zone
 command choosen, the varible "Z" holds the number of the Examine
 Zone selected and the mouse button is checked to see if it has been
 clicked in Zone 2. The MAP array holds all the exits for each
 location, the format of this is this.

  MAP(Location,Zone)

  Location= (The players present location)
  Zone= (The chosen Exit Zone)

 The Map array tells the game which location the player is in and
 which Exit Zone he has selected, it equals another location
 number so we can use it to connect a location to another location
 so in the above example we are connecting location 4 to location
 5 when the player clicks on Exit Zone 2. Other examples are..

  MAP(5,1)=10 : (Connects location 5 to 10 from Exit Zone 1)
  MAP(1,5)=2 : (Connects location 1 to 2 from Exit Zone 5)
  MAP(5,5)=8 : (Connects location 5 to 8 from Exit Zone 8)

 When we enter our Exit Zones in the Connections Menu, we can add
 False Exits Zones simply by entering nought when asked which
 location the previously selected zone leads to. so first our line
 checks if the Exit Zone is still a false exit before carrying out
 the rest of the line, if the zone is false  then MAP is set
 to nought to indicate it's un-connected.

 So the above line checks if Exit Zone 2 at location 4 is still
 un-connected, and if so, connects it to location 5, and prints a
 game message to tell the player that he has found an hidden
 passage behind the wall.

   Lines 3380 to 3440   (Load varibles)

 When you've been playing an adventure game for so long, its quite
 annoying to get so far then get killed, or have to finish the
 game to do something else. So what we Adventure Writers do is
 allow the player to save his or her postion in the game on disk
 and load it up when they play again to continue where they left
 off. This is done by the Stos file access commands.

 We shall look at saving in a moment, this section is used for
 loading the saved postion using the input# command.

 Unlike the "input" command which allows you to put a varible into
 memory, the "input#" allows you to take a varible from disk, so we
 can load it back into memory. So if we had a varible called
 TROLL, it would need to be saved as it was set to 1 and first but
 at the time of saving could have changed, so once it was saved we
 could load it back with "input#", like this.

 3380 input#1,TROLL

 The "#1" is the channel number, see Stos Manual for details.

   Lines 3470 to 3550  (Load number arrays)

 This section is used to load number arrays, for example.

  3470 for X=1 to 50 : input#1,OBJECT(x) : next X
  3480 for X=1 to 80 : for Y=1 to 5 : input#1,MAP(X,Y) : next Y :
      next X

   Lines 3570 to 3630  (Load word arrays)

 As above, but for loading word arrays, for example.

  3570 for X=1 to 100 : input#1,SHAPE$(X) : next X

   Lines 3730 to 3790  (Save varibles)

 Before we can load the varibles, we need to save them using the
 "print#" command like this.

 3730 print#1,TROLL

   Lines 3820 to 3900  (Save number arrays)

 As Load, this section is used to save number arrays.

 3820 for X=1 to 50 : print#1 OBJECT(X) : next X

   Lines 3920 to 3990  (Save word arrays)

 Guess what???, this is for saving word arrays.

 3920 for X=1 to 100 : print#1,SHAPE$(X) : next X

 Well thats the end of this Chapter, in Chapter 4 we shall have a
 look at the other zones and what can be done with them.